1. Field of the Invention
The invention relates to moving of flows in communication networks. Particularly, the invention relates to the swapping of packet flows between nodes or node interfaces in Internet Protocol (IP) based networks.
2. Description of the Related Art
Until recently still picture and hypertext based World Wide Web (WWW) browsing has been the predominant application in IP networks. WWW-page retrievals have constituted the largest stake of all Internet traffic. WWW-pages have mostly been browsed using fixed terminals. Through the use of Wireless Application Protocol (WAP) technologies or specific browsers that perform content adaptation, a portion of the content in WWW has recently been made available for mobile terminals.
However, recently multimedia streaming has gained importance as an IP network application. In multimedia streaming real-time video and audio presentations can be viewed over IP networks. A media stream represents, for instance, the video or the audio component in a multimedia session. The media stream comprises a continuous stream of packets that carry the encoded content between a content source and a client. Before the client is able to receive the media stream, it must have established a session with the content source. During the course of session establishment the client and the content source agree on media stream parameters such as content formats, bitrates, IP-addresses and port number for the stream. A multimedia session can be established, for instance, using the Internet Engineering Task Force (IETF) Session Initiation Protocol (SIP) specified in Request For Comments (RFC) document 3261 or the IETF Real-time Streaming Protocol (RTSP) specified in RFC 2326. The parameters associated with multimedia streams are described, for example, using the IETF Session Description Protocol (SDP) notation specified in RFC 2327, which is carried in session initiation signaling. In the media stream the encoded content is usually encapsulated in the IETF Real-Time Protocol (RTP) packets. The RTP is specified in RFC 1889. The purpose of the RTP is, for example, to carry timing information for the media streams, that is, media components.
The new Internet Protocol version IPv6 provides enhanced support for media streams via the concept of flows. In an IPv6 packet header there is a field called “Flow Label”, which enables multiple individual media streams i.e. flows associated with same destination IP addresses to be identified and separated. The concept of flow has several applications. Different flows can be treated differently in terms of Quality of Service (QoS). A router participating to the routing of packets between a source and a destination may inspect the flow identification in the packets and treat the packets differently. It is also possible that some intervening routers use the flow label instead of destination address in packet routing. The flow label specifies a predefined path via a number of routers. This kind of a solution, which is used, for example, in Multiprotocol Label Switching (MPLS), makes packet switching faster in intervening routers. The flows can also be utilized in a receiving system to identify individual media streams already at the IP layer. For example, it is possible to reroute packets from a given flow to another IP address.
With the introduction of the Mobile IP, which is specified in the IETF RFC 2002, it is possible to move nodes from one network interface to another and maintain a permanent or semi-permanent IP address, called a home address. In other words, the Mobile IP enables network layer mobility for nodes i.e. computer equipment connected to the Internet. The nodes may continue receiving packets wherever they happen to be attached to the Internet. The nodes may be attached either using fixed or wireless link layer connections. In the Mobile IP a node that has a home address and that may change its point of attachment is called a Mobile Node (MN). Packets destined to the MN home address are first sent to a Home Agent (HA). The HA is a router or computer node typically located in the mobile nodes home network. In IPv4 there is a Foreign Agent (FA), which is a router on a mobile node's visited network. The mobile nodes have link layer connection to the FA. The FA provides a pool of addresses for visiting mobile nodes in its care.
As the MN is attached to a new network interface, the MN must provide routing information for the HA so that it is able to route packets destined to the MN. In the case of the IPv4 the MN informs an address reserved from the FA to the HA. In the case of the IPv6 the MN informs the current network interface IP address to the HA. This address informing procedure is referred to as Binding Update (BU). The current network interface IP address or an address reserved from the FA is referred to as a Care-of-Address (CoA). When a packet destined to the MN home address is received by the HA, it maps the home address in the packet to the current care-of-address. In the case of the IPv4 the packet is tunneled to the FA and from there forwarded to the MN. In the case of the IPv6 the packet is sent by the HA directly to the MN. Namely, the IPv6 supports inherently the Mobile IP functionalities required to forward packets directly such as the re-mapping of the destination address to the home address.
In cases where text, still picture and application downloading based WWW- or WAP-browsing is used there is usually no need to transfer or swap browsing session related information between two terminals electronically, as a need arises to continue the browsing on another terminal. It might be useful to obtain browser cookies and bookmark information to another terminal, but this is not completely vital. The browsing session can be terminated at any moment in time on a first terminal and then later on continued on a second terminal even without transmitting information about a current page from the first terminal to the second terminal. Usually a user can without effort navigate back to the WWW-page last browsed. For convenience the WWW-address, in other words, the Uniform Resource Locator (URL) may have to be written down or sent to the second terminal using E-mail. In terms of the technical implementation the browsing session in the second terminal can be resumed from scratch by fetching WWW-page last browsed using a URL provided to the browser. Naturally, there are special cases where the site that has been browsed requires a login procedure, which must then be repeated in the second terminal.
The situation is much more difficult in the case of IP multimedia streaming sessions, if a given multimedia stream must be swapped on the fly to a second terminal. The user must resume manually the video or audio streaming at the point where it was interrupted at the first terminal. There may be additional complications such as the fact that the multimedia viewer software may have different settings and information concerning the quality of service and presentational characteristics of different types of multimedia streams. The presentational characteristics include such settings as window size for video, audio volume and bass boosting.
From the viewpoint of technical implementation the moving of a multimedia stream, in other words a flow, means that the first terminal must interrupt the flow at the flow source node. Thereupon, the second terminal must restart the flow at the second terminal.
Reference is now made to FIG. 1, which illustrates the aforementioned process for moving a flow between two nodes, in other words, terminals. In FIG. 1 there is a node 130 and a node 140. In this case node 130 and node 140 are mobile nodes with wireless link layer connections to the Internet. It should be noted that hereinafter in this disclosure, Internet refers to any IP network such as a corporate Intranet or any closed private IP network. Similarly, the nodes could as well be fixed network nodes connected, for example, to an Ethernet. In FIG. 1 there are two base stations, a base station 120 and a base station 122. There are two routers, a router 110 and a router 112. Base stations 120 and 122 are connected to routers 110 and 112 using connections 150 and 156, respectively. There is a media source 100, which is an arbitrary computer equipment capable of providing at least one media stream to node 130 or node 140. The media source may be, for example, providing a video stream. Media source 100 is connected to routers 110 and 112 using connections 152 and 154. The connections 150-156 are in this case IP network connections.
In FIG. 1, media source 100 provides a media stream, that is, a flow first to node 130 via router 110. Arrows 160 and 161 represent a given packet associated with the flow on its way towards node 130. When a user decides to move the flow to node 140, node 130 gives a request to media source 100 to stop transmitting packets associated with the flow. This is represented using arrows 162 and 163. The request may be, for example, an RTSP teardown message. When a user initiates the re-establishment of the flow at node 140, it requests media source 100 to start sending the media stream, that is, the flow to it. The request represented by arrows 164 and 165 specifies the multimedia content associated with the flow and the state of content consumption. The state of content consumption usually boils down to the time offset from the start of the content, which represents the video or audio content still remaining for the user. It should be noted that the re-establishment of a media stream, that is, a flow may take several requests and responses between node 140 and media source 100, but they have been omitted for simplicity. Arrows 166 and 167 represent the conveying of flow packets from media source 100 to node 140, as the flow has been re-established.
Without network layer mobility solutions, including, for example, the Mobile IP RFC 2002 and the IPv6, it would not be possible for the terminal to change network interfaces and thus temporary care-of-addresses at all. Always when the terminal moves between network interfaces, the flow would have to be interrupted at a first network interface and resumed later on at a second network interface. The Mobile IP alleviates this problem by enabling the terminal, that is, the mobile node to maintain a single home address. Flow packets can be streamed to the mobile node by a media source without it being necessary for the media source to be aware of the fact that the terminal changes network interface during the course of providing the flow.
Reference is now made to FIG. 2, which illustrates network layer mobility in providing a flow from a media source. In FIG. 2 there is a node 140, which is a mobile node. There are two base stations, base station 120, which is connected to router 110, and base station 122, which is connected to router 112. There is a media source 100, which provides a flow to node 140 continually without being aware of changes in the care-of-address of node 140. At first, base station 120 serves node 140. While being served by base station 120 node 140 has a first care-of-address. This care-of-address has earlier been registered by node 140 to a home agent 114, which has created a mapping between care-of-address and the home address of node 140. Media source 100 provides a flow of packets to node 140, which is represented by arrows 200, 201 and 202. The flow goes via HA 114, router 110 and base station 120. Gradually node 140 moves to the area of base station 122, where it will have a second care-of-address. When link layer establishment with base station 122 and care-of-address acquisition has been performed by node 140, it performs a binding update with HA 114. This involves the sending of binding update request, which is represented by arrows 203 and 204. Essentially, the binding update carries the current IP care-of-address. The binding update request carries as well data origin authentication information. The binding update is acknowledged by HA 114, which is represented by arrows 205 and 206. In practice, the registration procedures with base station 122 and binding update with HA 114 must be authenticated using public key signature technologies. This may involve the generation of nonce values by the base station or HA, which must then be included in the messages generated, signed and sent by node 140. When the binding update has been processed and approved by HA 114, it changes the home address of node 140 to point to the second care-of-address. This causes that the packet flow gets forwarded via router 112, base station 122 to node 140. The new route for flow packets is represented by arrows 207, 208 and 209.
A remaining disadvantage of a solution such as the one shown in FIG. 2 is that a flow cannot be transferred between two genuine nodes or two network interfaces connected to a single node that appear to the Internet as two individual nodes. One solution would be to make a binding update from the second node to a home agent, but this would exclude the possibility of continuing to receive part of traffic destined to the home address still to the first node. One solution to this problem has been introduced with multihoming protocols such as IETF Stream Control Transmission Protocol (SCTP), specified in RFC 2960 and in ITU-T signaling system no. 7 (SS7) Message Transfer Part (MTP). In multihoming protocols it is possible to have several simultaneous connections open from one sender to a number of receivers. The receivers may be genuinely separate hosts, that is, nodes or they may be alternative interfaces associated with a single node. All the alternative connections are continually kept alive between the sender and the receivers. If one of the connections fails, one of the remaining alternatives can be immediately used to reroute packets to the destination. This type of a solution is used in high-reliability environments such as voice over IP networks for signaling transfer.
Reference is now made to FIG. 3, which illustrates the principle of multihoming protocols. In FIG. 3 there is a media source 100, which has parallel connections 310-314 with hosts 300-304, respectively. The connections are over Internet 320, which can be, of course, any other IP network. In case there is a need for media source 100 to start forwarding flow packets via one of the alternative connections this can be done without further connection establishment since the required connections are already there.
The immediate disadvantage of a solution such as illustrated in FIG. 3 is that media source 100 must be aware of the alternative connection and support a multihoming protocol such as the SCTP. The use of this kind of protocols is uncommon in Internet and severely limits the availability of content services. Besides, it is not meaningful to implement flow mobility to all source nodes. This would require significant implementation and installation efforts. The flow mobility must be at least hidden from the content source application so that flow mobility must not be taken care at the application layer.